A three-tier architecture is an architecture in which the responsibilities for the user interface, the functional process logic (“business rules”), and the storage of data are divided between independent modules, which are often on separate platforms. Apart from the usual advantages of modular software with well defined interfaces, a three-tier architecture is intended to allow any of the three tiers to be upgraded or replaced independently as requirements or technology change.
The tiers of a three-tier architecture are typically named the presentation tier, the application tier, and the data tier. The presentation tier (or “top tier”) is responsible for implementing the user interface that facilitates interactions with a user. For example, the presentation tier is responsible for displaying information to a user and receiving instructions from a user.
The application tier (or “middle tier”) implements the functional process logic or business rules of an application. The middle tier may be multi-tiered itself (in which case the overall architecture is called an “n-tier architecture”).
The data tier (or “bottom tier”) is responsible for storing and retrieving data. For example, a data tier may be implemented using a database management system (DBMS) that comprises one or more database servers and one or more databases.
It is desirable for a three-tier architecture to process requests from a user as quickly as possible to minimize any delay experienced by the user. One approach for expediting the processing of user requests is to cache data in the application tier based on where the data is stored in the data tier. For example, if a particular user request requires the retrieval of a row of data from a database, then the entire data block in which the row of data resides may be retrieved from the database and stored in a cache of the application tier. This approach avoids the cost of retrieving data from the database in processing a subsequent request if the request may be processed using data from the cached data block in the application tier. Consequently, this approach works best when numerous requests may be processed using data stored in the same general location. However, this approach is not very useful when the physical location of data required to process a user request varies from request to request.